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AN INTELLIGENT PATIENT VISIT INFORMATION MANAGEMENT AND 

NAVIGATION SYSTEM 



Cross-Reference to Related Applications 

This application claims priority to United States Provisional Patent Application Serial 
No. 60/233,949, filed September 20, 2000, the disclosure of which is hereby expressly 
incorporated herein by referenced. 

Field of the Invention 

The invention relates generally to information management systems for use within the 
healthcare enterprises, and more particularly, to an intelligent system and method for managing 
and navigating patient information. 



Background of the Invention 

The provision of quality health care depends critically on timely and easy access to 
information that is most relevant to the patient's current condition. Computer-based clinical 
documentation systems have helped health care providers overcome many of the shortcomings of 
20 a paper-based system, including accessibility, portability, security and usability. However, as 
with any technological advance, the implementation of computer-based patient records has not 
only created new problems, but has also raised expectations about how health care information 
can be used in such a way that many of the known solutions and approaches are now seen as 
problematic. 

25 The successful implementation of computer technology by health care providers demands 

that they acquire computer skills that many providers view as an infringement upon their primary 
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purpose in seeing and treating patients. The demand for new skills and corresponding 
frustration is exacerbated by the increased expectations about the amount of patient information 
that should be recorded and available for use during any given patient encounter. The fact that a 
computer-based patient record presents a health care provider with a much larger set of potential 
5 information creates a corresponding imperative to both record and review moTe information 
while providing a patient's care. The problem is that eventually, the computer interface for 
accessing this wealth of information becomes nearly as cumbersome to deal with as a paper 
chart. Typing to enter information while clicking or scrolling through a myriad of windows, 
forms or screens can be as distracting and nearly as inefficient as flipping through pages of 
10 paper. 

Existing computer-based record systems have partially resolved this problem by limiting 
the amount of manual typing and navigation required to access and record information for a 
given patient visit. A typical solution is to provide a summary of key data elements in a single 
window and to collapse access to the underlying data into a hierarchical navigation interface. 

1 5 The interface allows users to drill down to a specific data element by pointing and clicking 

within the interface, and to enter data by the same means. By presenting users with rapid access 
to information that is most relevant to their current patient visit, these solutions make it easier for 
health care providers to use and add to the information available within a computerized patient 
record. In order to ensure that these ease-of-use features remain flexible for use among diverse 

20 health care providers with even more diverse patient populations, it is even more desirable to 
embed these features as templates within the user interface. A template-based approach allows 
providers to choose from a number of different summary/navigation views and use the one that is 
most appropriate for the given circumstances. 
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However, this solution is ultimately unsatisfactory, because of the frequency with which 
health issues will arise that a template was not designed to address. The obvious attempts to 
resolve this difficulty also prove unsatisfactory. First, simply creating more templates means 
that the provider will face the problem of knowing the differences between each template in 
5 advance, and the choice may ultimately prove unsatisfactory anyway. For example, you could 
create a number of different variations of each standard template, but in order to use this set of 
variations efficiently you would have to be familiar with the specific differences between each 
template. And even if you choose what looks to be the right template at the start of a visit, you 
may uncover information in the course of that visit that is no longer easy to capture with the 

1 0 original template. Second, building more complexity into a smaller set of templates tends to 
defeat the purpose for having templates in the first place. The more complexity you add to a 
standard template, the more it looks like the complex system that the template is intended to 
simplify. Third, allowing a user to embed dictated notes to extend the usefulness of any given 
template undermines some of the advantages afforded by using a computerized record in the first 

1 5 place. Dictated notes must be transcribed if they are to be viewable online, and the elimination 
of transcription costs is one of the major benefits associated with implementing a computerized 
health record system. Even if you manage to successfully automate the transcription process, 
you lose the benefits associated with storing visit information as structured data. Dictation 
blocks of text, because they are unstructured (i.e., are filed in the database as free text rather than 

20 as discrete data items such as diagnosis codes), are unavailable for use in decision support, data 
mining and reporting. 

So even with the above-listed improvements, the tension between ease-of-use and 
flexibility for recording patient encounter information persists within existing solutions to 
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providing a computerized patient record. The objective of the present invention is to provide a 
computerized patient record system that takes full advantage of an easy-to-use navigation 
interface and summary view but which does so without sacrificing the flexibility and power 
associated with a robust database of information. 

5 

Brief Description of the Drawings 

FIG. 1 is a block diagram illustrating a patient health record system in accordance with a 
preferred embodiment of the present invention. 

FIG. 2 is a block diagram illustration of a graphic user interface of the patient health 
10 record system illustrated in FIG. 1. 

FIG. 3 is a flowchart representing the general operation of a system in accordance with a 
preferred embodiment of the invention. 

FIG. 4 is a flowchart representing a visit template engine in accordance with a preferred 
embodiment of the invention. 
15 FIG. 5 is a flowchart representing a process for editing visit information. 



Detailed Description of the Preferred Embodiments 

In accordance with an embodiment of the invention, a patient health record system uses 
knowledge bases to dynamically build visit templates and suggest content based on the user's 
20 profile and current patient information. The visit template is available to the health care provider 
using the system, and is presented within an easy-to-use graphical interface comprising a 
navigation pane for moving from one section of the template to another, and a visit information 
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window that displays current visit information and allows the user to add and edit that 
information. 

Referring to FIG. 1, an enteiprise patient health record system 10 includes a number of 
data elements 12 for supporting the patient information needs of the healthcare enterprise. As 
5 shown in FIG. 1, the system 10 includes a patients element 14, a providers element 16 and a user 
security element 18. These elements, for example, provide to the system 10 respective data 
services. For example, the patient element 14 includes a data structure for organizing and storing 
patient information and may incorporate processing and communication capability to allow the 
element to interface with the other elements of system 10 for receiving, organizing and storing 

10 patient information and for retrieving and delivering patient information. Of course the 

processing and communication capability may be centralized within the system 10, in which case 
the respective element would include just the appropriate data structure for organizing and 
retaining data. The system 10 further includes supporting data structure element 22 to fully 
support patient health records. 

15 The system 10 also includes a patient visit information element 20. The patient visit 

information element 20 contains the information types that are used to dynamically build 
templates as well as to provide content suggestion. As will be described in more detail below, 
the visit template for the patient visit contains sections for displaying, recording and updating 
different types of visit information. These types of information include, but are not limited to, 

20 patient vital signs, medications, allergies, nursing notes, charting notes, progress notes, problem 
list, diagnoses, orders, patient instructions, follow up, level of service and any other information 
that may be relevant to the patient's visit. This information is stored in the system 10 for the 
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particular patient along with other information necessary for maintaining the patient health 
records. 

Further included with the data elements 12 are a section definition template knowledge 
base 24 and a content template knowledge base 26. The section definition template knowledge 
5 base 24 contains visit information types that are grouped into section definition templates. These 
templates are linked to encounter types, e.g., "office visit." The content template knowledge 
base 26 contains individual content selections that are grouped into content templates. These 
templates are linked to locator data that are documented as part of the visit, such as "chief 
complaint - back pain." 

10 The data elements 12 are linked within the system 10 to the visit navigator tool 32 via a 

user security engine 28 and a record access manager 30. The user security engine 28 provides 
view and edit access security to limit user access to patient information in accordance with user 
security information, such as security profile, role, etc. The user security information is 
maintained within the user security element 18. The record access manager 30 locks patient 

1 5 records in response to user actions. The entire patient record is not locked, such that information 
unrelated to the visit encounter becomes unavailable system wide. Instead, only the portion 
relevant to the user's actions is locked. This provides for higher availability of patient 
information throughout the system. 

The tool 32 includes a visit template engine 34 and a visit information manager 36. The 

20 visit template engine 34 determines sections (visit information types) to be included in the visit 
template based on the user profile, encounter type, and the section definition template knowledge 
base 24. The visit template engine 34 uses the current patient information as well as the content 
template knowledge base to add suggested content to the visit template. The user is permitted to 
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select suggested content with point-and-click or similar actions. In addition, the tool 32 can be 
configured to allow changes and updates to visit templates in response to changes to the visit 
information. The visit information manager 36 processes the users input and updates the display 
of the visit information. 

5 The tool 32 drives a graphic user interface (GUI) 38 shown in FIG. 2. The GUI 38 may 

have a web browser or other suitable appearance, and includes an activity header 40, an activity 
toolbar 42 and a template section 44. The activity header may provide patient information, such 
as patient name, sex, age, insurance and other demographic information. The activity toolbar 42 
contains point-and-click activity selections, which allows the user to activate the tool 32, obtain 

10 patient information from the system, place orders, complete the encounter, etc* 

Within the template section 44, there is a patient information header 46, a navigation bar 
48 and a visit information window 50. The patient information header 46 provides general 
patient information for the current patient For example, the current patient's known allergies 
and vital signs may be displayed. The information within the header 46 can be configured to 

1 5 display different information based on the user profile, the encounter type, etc. The navigation 
bar 48 permits the user to jump to corresponding sections of the visit information within the visit 
information window 50 using point-and-click or similar action. Within the visit information 
window 50, the user is able to select suggested content with point-and-click or similar action. 
The user can also scroll through information and select any section of information to expand it 

20 for editing. 

In use, when the user creates a new patient visit record or opens an existing record, the 
tool 32 dynamically builds the visit template within the visit information window and suggests 
content using the visit template engine 34. The engine 34 first determines what sections of visit 
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information (as described above) are appropriate for the user and the encounter type. Section 
definitions for visit templates are maintained in a section definition template knowledge base 24. 
The section definition template for an office visit may define all of the sections listed above for 
the visit template, while the template for an immunization administration encounter would define 
5 fewer sections. 

The system 10 also checks the user's security profile for a specified section definition 
template that corresponds with the visit's assigned encounter type. If there are no templates 
defined in the user's profile, the visit template engine 34 uses a default section definition 
template. The system displays the sections that compose the selected visit template in the 
1 0 navigation pane 48 and the visit information window 50. 

Within each section of visit information, the engine 34 may display suggested content 
that is appropriate for the current user, visit and/or patient health status. The visit template 
engine 34 retrieves suggested content from the content template knowledge base 26, adding 
individual content selections to corresponding sections within the visit template (for example, 
1 5 "Common migraine" to the Diagnosis section). 

The engine 34 also suggests content for any section based on a variety of patient, user 
and visit information. This information— chief complaint, visit diagnoses, department 
specialties, etc., is linked to content templates as locator data. When the data documented during 
a visit matches the locator data assigned to a content template, the engine 34 selects that content 
20 , template. For example, if a content template has a chief complaint locator of "physical exam," 
when the user documents "physical exam" as the visit's chief complaint, the content template is 
incorporated into the visit template. 
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The engine 34 may operate in a substantially more intelligent manner than simply 
suggesting templates based on one or more pieces of patient information taken from the current 
encounter. The engine 34 is designed to intelligently suggest content for the template based 
upon all available information known about the patient retained in the system 10, to develop 
5 content for the template presented to the caregiver. Thus, the engine 34, working from the 
content template knowledge base 26 and using all of the available patient information, such as, 
current medications, lab results, lab trends, problem list, etc., builds the template during the visit. 

The system 10 can also dynamically update content suggestions as visit information is 
changed or added within the visit information window, thereby constantly responding to the 
10 user's input. For example, after a doctor enters a visit diagnosis the tool 32 may dynamically 
suggest patient instructions, medications, or follow-up actions appropriate to that diagnosis. The 
doctor can then either follow the rule-based suggestions with a simple point-and-click action or 
similar selection mechanism, or can alternatively select other actions by using the pop up editing 
window for the given content type. 
15 Suggested content can include such things as individual diagnosis and procedure codes, 

medications, and blocks of text specifically geared towards the current patient through automatic 
links to patient record information (vitals, lab results, etc.). Additional suggested content may 
include best practices guidelines, which may help prevent errors by preventing errors of 
omission. The user can use suggested content by selecting the appropriate command in the visit 
20 information window 50. 

In addition to links to patient-specific information, the text blocks described above can 
contain user-defined selection lists that allow the user to quickly tailor the text to a specific 
patient visit by selecting the proper elements within the selection list (for example, "in mild 
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distress" from a "General Appearance" selection list). Within the system 10 the selection lists 
can be configured as structured data (i.e., filed in the database as discrete data items) for 
reporting and decision support purposes. In addition to using suggested content, the user can 
also add his or her own content by either typing directly in text fields or by typing entries or 
5 using drop down lists for discrete data items. 

Within the visit information window 50, all sections are displayed as read-only text until 
a user with editing security opens a section for editing by selecting the appropriate command. 
The section then expands from view-only to editing mode and the data elements contained 
therein are locked from. editing by any other user by the record access manager 30. This inline 

10 expansion not only makes it easier to scan and read the visit information because it is all listed in 
an easy-to-scroll window, but it also makes it easy for multiple users to view and edit 
information in the patient visit without data conflicts, because a section is not locked until a user 
activates it for editing. With this data-locking scheme a nurse could be documenting the 
administration of an immunization while the physician updates progress notes for the visit or 

1 5 documents a visit diagnoses or level of service. 

The system 10, by combining an easy to use navigation and information interface with 
knowledge base-driven templates, represents a solution that is both easier to use and more 
flexible than existing systems. Users of this system can harvest the full potential of a 
computerized patient record without need of extensive data-entry and computer expertise. 

20 Referring now to FIG. 3, the user workflow 300 is described in additional detail. 

Starting at 301 , a logged in user opens an available patient record, 300. Upon doing so, the user 
security engine 28 determines authorized activities for the user and displays options in the 
activity bar 42 of the GUI 38. Based on the user security profile, if the user is not authorized to 
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view the visit information for the active patient, 307, the workflow ends, 309. Otherwise, to 
activate the visit navigation tool 32, the user selects the visit navigation activity from the activity 
toolbar 42. 

Again, based on the user's security profile, the user security engine 28 determines 
5 whether edit or view only access is available to the user for each type of visit information, 313. 
At 315, the tool 32 determines appropriate visit template sections based on the user profile and 
encounter type using the section definition template knowledge base 24, 315, and adds suggested 
content based on current patient information using the content template knowledge base 26, 315. 
The tool 32 then displays the read-only view of the visit information for the current patient in the 
10 visit information window 50, and marks information types that can be edited by the current user, 
319. 

From within the visit information window 50, the user may perform a number of different 
tasks including: selecting visit information from the navigation bar 48, 323, selecting patient 
information to edit from within the visit information window 50, 327; selecting suggested 

15 content from within the visit information window 50, 337; and selecting another activity from 
the activity toolbar 42, 343. When the user selects visit information from the navigation bar 48, 
the visit information window 50 scrolls to the selected visit information 325. Selecting patient 
information to edit causes the tool 32 to call a visit information editing routine for the selected 
visit information type, and loads the patient information to be edit, 329. The record access 

20 manager 30 locks the active visit information within the system 10, 33 1 , so that others may not 
edit it. The tool 32 then displays an editing popup in the visit information window 50. Selecting 
suggested content causes the tool 32 to perform a confirmation process for the content type, 339. 
The confirmation process, which may occur before the user is presented with a list of choices of 



-11- 



WO 02/25565 PCT/US01/29124 
selected content, verifies that the suggested content is appropriate for the age, gender, etc. of the 
patient to ensure the caregiver is only presented with a valid list of choices.The tool 32 updates 
the patient information with the selected content, 341. 

Selecting another activity from the activity toolbar 42 causes a number of actions. First, 
if there is an open editing popup for visit information, 345, the tool 32 displays a warning and 
presents choices to cancel or proceed and lose changes to any edited information, 351. By 
selecting not to proceed, 353, the visit information window 50 scrolls to the open editing popup, 
355. If there are no active editing popups, 345, or if the user elects to proceed, 353, the tool 32 
closes, 347 and the workflow is ended. 

Referring now to FIG. 4, the workflow 400 associated with the visit template engine 34 
is discussed in greater detail. When a logged-in user opens a patient record and selects the visit 
navigation tool 32 activity, 401, the visit navigator engine 34 checks an encounter type assigned 
to the visit against encounter types listed in the user's profile, 403. If there is a match found, the 
engine 34 selects the template from the section definition template knowledge base 24 that is 
identified in the user's profile for that encounter type, 405. Otherwise, the engine 34 selects a 
default template from the section definition template knowledge base 24, 407. The tool 32 then 
displays in the visit information window 50, the visit information types defined in the active, i.e., 
selected, section definition template, 409. 

A check is made to determine if content template locator data has been documented, 41 1. 
If not, no default content choices are available, 413, resulting in no matches being found. If 
content template locator data is documented, the engine 34 checks documented locator data 
against locator data assigned to content templates in the content template knowledge base 26, 
415. The engine 34 then selects the content template(s) whose assigned locator data corresponds 
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to the documented locator data, 417, and for each selected content template, the engine 34 
identifies individual content selections within the template that correspond to the active sections 
of the selected visit template, 419. For each section of the visit template, the tool 32 displays 
corresponding content selections from the content templates selected by the engine 34, 421. 
5 FIG. 5 illustrates the workflow 500 for editing visit information. When a user selects 

patient information for editing (327 of FIG. 3b), the result is an editing popup being displayed in 
the visit information window (333 of FIG. 3b), which starts the editing workflow, 355. 
Exemplary types of visit information that maybe edited are: chief complaint, 501; vital signs, 
503; history of present illness, 505; current medications, 507; allergies, 509; exam notes, 511; 

10 diagnoses, 513; progress notes, 515; review of systems, 517; orders, 519; patient instructions, 
521 ; follow-up, 523; and level of service, 525. If data is to be added, 527, the user enters the 
data based upon the fields for the data, e.g., charting template, free text, master file, or category 
list selection, 529. Standardized words and phrases, and methods to predict words and phrases to 
be entered, may be used to facilitate and simplify the data entry. Data may also be deleted, 53 1 , 

15 by deleting data from the selected field, 533. After either adding or deleting data, the user is 
offered the opportunity to save the edited data, 535. If the user decides not to save the edited 
data, 535, the user clicks a button to restore the previously saved data, and the editing popup 
remains open. If the user elects to save the edited data, 535, the user may elect to move to the 
previous data entry screen in the visit template, 529. Doing so causes the data to be saved and 

20 the tool 32 to navigate to the previous data entry screen, 541. The tool 32 then displays the 

updated content selections from the content templates located by the engine 34, 547. If the user 
elects not to move to the previous data entry screen, 539, the user may elect to move to the next 
data entry screen, 543. Doing so causes the edited data to be saved, and the tool 32 to navigate 
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to the next data entry screen, 545. The tool 32 then displays the updated content selections from 
the content templates located by the engine 34, 547. The user may elect not to edit the next data 
entry, ending data editing. Doing so causes the edited data to be saved, 551 and the tool 32 to 
display the updated content selections from the content templates located by the engine 34, 553 
5 and returns to the workflow 300. 

The invention has been described in terms of several embodiments, including a number 
of features and functions. Not all features and functions are required for every embodiment of 
the invention, and in this manner the invention provides a flexible system by which a user may 
manage and navigate patient visit information. The features discussed herein are intended to be 
10 illustrative of those features that may be implemented; however, such features should not be 

considered exhaustive of all possible features that may be implemented in a system configured in 
accordance with the embodiments of the invention. 
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CLAIMS 

We claim: 

1 . An enterprise health record system comprising: 

a database server with a plurality of data structures, wherein the data structures are 
adapted to store at least patient information, user information, a knowledge base for dynamically 
building and updating patient visit documentation templates and associated suggested content; 
and 

a graphical user interface coupled to the database server, the graphical user interface 
including a navigation window and a visit information window within which patient information 
is displayed in accordance with a visit template; 

wherein the visit template is dynamically based upon at least one of the patient 
information, the user information, the knowledge base and the suggested content. 

2. The enterprise health record system of claim 1, wherein the visit template is dynamically 
based upon each of the patient information, the user information, the knowledge base and the 
suggested content. 

3. The enterprise health record system of claim 1 , wherein the knowledge base comprises at 
least one of a section definition template knowledge base and a content template knowledge 
base. 

4. The enterprise health record system of claim 1, wherein the graphical user interface 
comprises at least one of icons and text representing sections of the visit template. 
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5. The enterprise health record system of claim 1, where the navigation window comprises 
at least one of icons and text associated with sections of the visit template and permitting 
jumping to the associated section of text based on selection of the respective icon or text. 

5 

6. The enterprise health record system of claim 1 , further comprising a template engine, 
wherein the template engine comprises a user profile engine that dynamically arranges the 
display of the patient information in the visit information window based upon user information 
and a template building knowledge base. 

10 

7. The enterprise health record system of claim 1 , further comprising a decision support 
engine, wherein the decision support engine dynamically arranges the display based upon user, 
patient and visit information and a template building knowledge base. 

15 8. The enterprise health record system of claim 7, wherein the decision support engine 
suggests additional content to be displayed in the visit information window. 

9. The enterprise health record system of claim 1, wherein the patient information is 
scrollable within the visit information window. 

20 

10. The enterprise health record system of claim 1 , further comprising an editor for editing 
the patient information. 
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1 1 . The enterprise health record system of claim 10, wherein the editor comprises a records 
manager for selectively locking a portion of the patient information to be edited. 

12. The enterprise health record system of claim 10, wherein the editor is enabled based upon 
S a security profile of the user. 

13. . The enterprise health record system of claim 1, wherein the user information comprises a 
user security profile. 

10 14. The enterprise health record system of claim 1, wherein the patient information is 
organized within the visit template in sections, the sections being expandable. 

15. The enterprise health record system of claim 1 , wherein the patient information 
comprises visit encounter information. 

15 
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16. A method of displaying patient information within an enterprise health record system, 
the method comprising the steps of: 

dynamically building a visit template and associated content to be displayed within the 
visit template using patient information, user information and a knowledge base; and 
5 graphically displaying the patient information within the visit template on a graphic 

display. 



1 7. The method of claim 1 6, further comprising linking the patient information to graphic 
representations, and collecting the graphic representations within a navigation portion of the 
10 graphic display. 



18. The method of claim 17, wherein the graphic representations comprise at least one of text 
and icons. 



15 19. The method of claim 16, wherein the step of dynamically building a visit template 
comprises suggesting content for the visit template. 

20. The method of claim 1 6, wherein the knowledge base comprises at least one of section 
definition template knowledge base and a content template knowledge base. 

20 

2 1 . The method of claim 16, wherein the patient information comprises an encounter type. 
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22. The method of claim 16, further comprising scrolling the patient information within the 
visit template in response to a user input. 

23. The method of claim 16, providing an editing popup associated with the patient 
5 information. 

24. The method of claim 16, further comprising locking a portion of the patient information 
during editing of the portion. 
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